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Network  and  Graph  Markup  Language  (NaGML)  -  Data  File  Formats 


Gordon  H.  Bradley 
Operations  Research  Department 
Naval  Postgraduate  School 
Monterey,  CA  93943 
bradley@nps.edu 

Abstract 

The  Network  and  Graph  Markup  Language  (NaGML)  is  a  family 
of  Extensible  Markup  Language  (xml)  languages  for  network  and  graph 
data  fdes.  The  topology,  node  properties,  and  arc  properties  are  validated 
against  the  user’s  specification  for  the  data  values.  NaGML  is  part  of  a 
component  architecture  that  reads,  validates,  processes,  displays,  and 
writes  network  and  graph  data.  NaGML  supports  a  variety  of  data  file 
formats  that  are  described  here. 

Introduction 

The  Network  and  Graph  Project  is  constructing  a  suite  of  tools  to  read,  validate, 
process,  display,  and  write  networks  and  graphs.  The  centerpiece  is  the  NaGML  that  is  a 
family  of  xml  languages  to  represent  the  topology  (nodes,  arcs,  node  sets,  arc  sets,  and 
subgraphs),  node  properties,  and  arc  properties.  The  author  of  the  data  file  specifies  the 
name  and  data  type  for  each  property  as  well  as  additional  restrictions  on  the  data  values. 
The  topology  and  values  of  the  node  and  arc  properties  are  validated  using  XML  Schema 
technology.  The  NaGML  family  supports  a  variety  of  data  file  formats  that  correspond  to 
common  data  formats  for  networks  and  graphs. 

NaGML  has  been  designed  to  support  the  vigorous  and  diverse  community  of 
people  who  use  network  and  graphs  for  many  purposes,  in  a  variety  of  contexts. 
Applications  involve  problem  instances  that  range  from  a  handful  of  nodes  to  ones  with 
thousands  and  even  millions  of  nodes  and  arcs.  Network  and  graph  instances  are 
constructed  to  model,  analyze,  solve,  design,  display,  and  entertain.  For  example, 
mathematicians  and  social  scientists  analyze  structure,  operations  researchers  and 
computer  scientists  compute  optimal  flows  and  efficient  structures,  engineers  design 
roads  and  computer  chips,  planners  develop  land  use,  contractors  schedule  projects, 
graphic  artists  develop  static  and  dynamic  displays,  scientists  map  molecules  and  solar 
systems,  and  intelligence  analysts  try  to  “connect  the  dots.” 

NaGML  is  supported  by  a  component  architecture  that  includes  separate  programs 
to  read  data  files,  validate  the  topology  and  properties,  construct  internal  data  stores, 
execute  algorithms,  display  static  and  dynamic  views,  link  to  external  systems  (for 
example,  spreadsheets  and  databases),  and  construct  data  files.  The  architecture  is 
“loosely  coupled”  in  the  sense  that  it  consists  of  components  with  well-defined  interfaces 
that  allow  multiple  implementations  of  each  component.  This  allows  a  user  to  construct  a 
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system  from  components  that  best  meets  their  needs  and  it  allows  contributors  to 
construct  their  own  components  that  work  with  other  components  in  the  system. 

NaGML  and  the  architecture  is  intended  to  support  the  widest  possible  audience 
of  people  who  use  networks  and  graphs  as  well  as  people  who  construct  algorithms  for 
them.  The  NaGML  system  has  easy  entry  points  that  help  the  casual  user  construct  and 
manipulate  small  instances.  It  is  also  scales  up  to  the  large  instances  that  may  be 
constructed  and  consumed  by  production  programs.  This  surprising  capability  to  support 
a  wide  range  of  users  with  a  variety  of  requirements  is  based  on  the  flexibility  of 
NaGML.  NaGML  achieves  this  by  being  not  a  single  xml  language,  but  rather  a  family  of 
xml  languages  whose  construction  is  hidden  from  the  user.  Each  user  employs  the 
capabilities  of  a  custom-built  xml  language  that  is  automatically  constructed  and  applied. 

Networks  and  Graphs 

A  graph  is  a  non-empty  set  of  nodes,  together  with  a  set  of  arcs,  that  are  defined 
as  pairs  of  nodes.  The  arcs  can  be  directed  (one  node  is  the  tail,  the  other  the  head)  or 
undirected.  A  network  is  a  graph  with  one  or  more  properties  associated  with  each  node 
and  each  arc.  Each  property  has  a  fixed  data  type;  there  is  a  wide  range  of  possible  data 
types,  for  example,  integer,  double,  boolean,  string,  etc.  Nodes  might  have  properties 
such  as  location  (x-y  or  lat-long),  cost,  and  description.  Arc  properties  might  be  length, 
name,  cost,  open-shut,  etc. 

Common  examples  are  road  and  street  networks,  water  and  power  grids,  and 
communications  networks.  In  addition  to  these  obvious  physical  networks,  networks  (and 
sometimes  graphs)  model  a  wide  variety  of  other  applications  such  as  assigning  people  to 
jobs,  scheduling,  bid  evaluation,  organization  charts,  and  circuit  board  layout.  Virtually 
all  the  applications  envisioned  for  NaGML  have  node  or  arc  properties  (or  both)  and  are 
thus  networks  rather  than  graphs;  the  “and  graphs”  was  added  to  distinguish  NaGML 
from  markup  for  other  networks  that  do  not  have  nodes  and  arcs.  In  the  subsequent 
discussion  we  drop  the  “and  graph.” 

Networks  data  files  are  often  input  for  a  variety  of  algorithms  that  construct 
shortest  paths,  detennine  the  flow  of  goods,  schedule  activities,  design  chips,  etc.  Some 
applications  use  networks  as  a  data  model  to  structure  data.  These  applications  use 
networks  to  store,  and  perhaps  visualize,  data.  Some  applications  may  involve  only  nodes 
and  node  properties;  for  example,  data  about  locations  (nodes)  displayed  on  a  map. 
NaGML  capabilities  support  these  diverse  applications. 

Xml  with  a  NaGML  Example 

Xml  is  a  metalanguage  for  defining  xml  documents.  Xml  is  not  a  language  itself; 
instead  it  is  a  set  of  rules  to  define  and  construct  xml  documents.  Markup  is  text  that  is 
added  to  a  document  to  add  meaning  and  structure  that  can  then  be  used  to  automate 
processing  of  the  document.  This  modest  description  hides  the  full  range  of  capabilities 
that  have  been  built  around  and  on  top  of  xml  and  that  have  lead  to  the  rapid  and 
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widespread  use  of  xml  and  xml-related  technologies.  See  [13]  and  [8]  for  a  discussion  of 
xml,  see  [2]  [1]  for  a  discussion  with  operations  research  examples. 

Xml  is  an  open  source  standard  that  was  developed  by,  and  is  supported  by,  the 
World  Wide  Web  Consortium  (W3C)  [15].  It  is  platform  independent.  There  are  a 
number  of  free,  open  source  tools  as  well  as  proprietary  tools  available  for  the  efficient 
construction  and  processing  of  xml  documents. 

As  shown  in  Figure  1,  xml  markup  consists  of  elements  and  attributes.  The 
elements  are  enclosed  by  a  start  tag:  <Node  nodeID="l">  that  begins  with  the 
name  of  the  element  and  optionally  includes  name-value  pairs  called  attributes.  Each 
element  must  be  closed  with  a  matching  end  tag:  </Node>.  Elements  can  include  other 
elements  and  also  text  (also  called  PC  Data).  The  text  of  an  element  is  everything 
between  the  start  tag  and  the  end  tag  that  is  not  enclosed  in  another  element.  Here  we 
follow  common  practice  that  an  element  either  contains  other  elements  or  text,  but  not 
both.  Elements  are  fully  nested  in  that  any  start  tag  must  be  matched  with  its  end  tag 
inside  any  enclosing  element.  An  element  may  also  be  an  “empty”  element  that  combines 
the  start  and  end  tags: 

<Arc  tail  ="2"  head="l"/> 


<?xml  version="l . 0"  encoding="UTF-8"?> 

<!--  NetworkAndGraphML  for  networks  and  graphs  --> 

<NaGXML  xmlns : xsi="http : / /www .w3.org/ 2001 /XMLSchema-instance"> 
<Description> 

<Network  name="Figure  l"/> 

<NodeProperties> 

<NodeProperty  name="Xpixel" 
dataType="xs : nonNegativeInteger"/> 

<NodeProperty  name="Ypixel" 
dataType="xs : nonNegativeInteger"/> 

<NodeProperty  name="Symbol"  dataType="xs : string"/> 
</NodeProperties> 

<ArcProperties> 

<ArcProperty  name=" Length"  dataType="xs :double"/> 
</ArcProperties> 

</Description> 

<Data> 

<Node  nodeID="l"> 

<Xpixel>100</Xpixel> 

<Ypixel>100</Ypixel> 

<Symbol>black  circle</Symbol> 

</Node> 

<Node  nodeID="2"> 

<Xpixel>100</Xpixel> 

<Ypixel>200</Ypixel> 

<Symbol>red  circle</Symbol> 

</Node> 

<Node  nodeID="15"> 

<Xpixel>300</Xpixel> 

<Ypixel>200</Ypixel> 

<Symbol>blue  square</Symbol> 
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</Node> 

<Node  nodeID="4"> 

<Xpixel>350</Xpixel> 

<Ypixel>125</Ypixel> 

<Symbol>blue  square</Symbol> 

</Node> 

<Arc  tail  ="4"  head="15"> 

<Length>34 . 5</Length> 

</Arc> 

<Arc  tail  ="2"  head="4"> 

<Length>160 . 0</Length> 

</Arc> 

<Arc  tail  ="15"  head="4"> 

<Length>200 . 0</Length> 

</Arc> 

<Arc  tail  ="2"  head="l"/> 

<Arc  tail  ="1"  head="4"> 

<Length>120 . 4</Length> 

</Arc> 

</Data> 

</NaGXML> 

Figure  1  Simple  data  file  format  that  uses  defaults  for  node  and  arc  identification. 

Each  xml  document  must  have  a  unique  “root”  element.  An  xml  document  is  a 
rooted  tree  that  is  almost  always  written  in  the  indented  format  of  Figure  1,  rather  than  as 
a  tree  with  nodes  and  directed  arcs.  By  convention,  element  names  begin  with  upper  case 
letters.  The  name  of  an  attribute  is  always  followed  by  an  equal  sign  and  the  value  of  the 
attribute  in  double  quotes:  name="Length"  dataType="xs  :  double"  .  We 
follow  the  convention  that  attribute  names  begin  with  lower  case  letters;  in  the  text  of  this 
paper  we  will  italicize  attribute  names  to  make  them  stand  out. 

Since  the  network  and  graph  community  is  international  in  scope,  and  since  a  data 
file  format  standard  should  be  constructed  to  survive  many  years,  it  is  appropriate  that 
NaGML  use  xml  and  fully  embrace  the  internationalization  that  choice  allows.  Xml  is  not 
“ANSI-centric”  nor  is  it  “English-centric.”  It  is  character  based  (as  opposed  to  binary) 
and  contains  full  support  for  all  character  sets  and  all  human  languages.  In  addition  to 
support  for  English,  there  are  over  35  different  encodings.  The  practical  reality  is  that 
today  (2004)  few  of  the  35+  encodings  that  have  been  designed  have  been  implemented 
into  working  code.  However,  by  providing  for  multiple  encodings,  xml  has  laid  the 
foundation  for  full  internationalization,  and  thus  made  it  likely  that  xml  will  remain  a 
dominant  data  store  format  for  decades,  if  not  centuries. 

An  xml  language  (also  called  a  tag  set,  an  xml  vocabulary,  document  type,  xml 
dialect)  is  a  specification  for  a  set  of  xml  documents  that  places  restrictions  on  the  names 
of  elements  and  attributes,  the  structure  of  the  elements,  and  the  values  of  the  data.  Each 
xml  language  should  have  a  schema  that  is  a  formal  specification  of  these  restrictions.  An 
xml  document  is  an  instance  of  a  particular  xml  language  if  it  conforms  to  the  schema 
that  defines  the  language;  this  is  determined  by  validating  parser  [8] [14] [5]. 
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There  are  many  xml  languages;  a  few,  such  as  XHTML,  SVG,  and  MATHML, 
are  well  known  and  widely  used;  however,  many  xml  languages  have  been  defined  for 
special  applications  with  limited  use.  Xml  languages  are  valuable  because  they  impose 
restrictions  on  the  structure  and  content  of  documents  that  can  be  validated  using  the 
schema  and  widely  available  validating  parsers.  This  process  makes  it  easy  to  check  a 
data  file  for  errors  and  reduces  the  complexity  of  any  program  that  reads  a  validated  xml 
document.  In  addition  to  reducing  the  error  checking  that  must  be  done  by  a  program  that 
process  an  xml  document,  validation  supports  interoperability  of  documents  (often  over 
the  Web).  The  producer  of  data  can  validate  a  data  file  before  sending  it  to  someone  or 
some  application  for  further  processing.  The  validation  by  the  data  producer  helps 
identify  data  errors  as  the  data  is  produced — this  is  the  time  and  place  where  it  is  most 
effective  to  correct  errors.  Consumers  of  validated  data  know  that  the  data  file  confonns 
to  the  schema  and  thus  does  not  contain  certain  errors  in  structure  and  content. 

Defining  a  new  xml  language  is  a  difficult  task  that  often  involves  some  serious 
trade-offs.  One  goal  is  to  make  the  language  comprehensible  and  flexible,  so  that  as  many 
people  as  possible  adopt  it  as  a  standard.  Wide  adoption  supports  interoperability  of  data 
and  can  lead  to  the  development  of  associated  software  to  read,  write,  process,  transform, 
and  visualize  data  files.  Another  goal  is  to  make  the  xml  language  extensible,  so  that  it 
can  accommodate  evolving  user  requirements.  The  final  goal  is  that  the  schema  be 
detailed  and  comprehensive,  so  that  it  enforces  strong  validation  on  xml  documents. 

NaG  Loosely  Coupled  Components  Architecture 

From  its  inception,  NaGML  has  been  much  broader  than  just  a  markup  language. 
The  NaG  Project  includes  a  design  for  a  comprehensive  software  system  for  networks 
that  supports  the  full  spectrum  of  processing  including:  construct,  read,  validate,  store, 
solve,  display,  link,  and  write.  This  includes  multiple  data  structures  so  that  an  algorithm 
can  be  paired  with  a  data  structure  that  best  supports  its  calculations,  visualization  of  both 
static  structures  and  dynamic  processes  so  that  algorithms  can  be  animated  and  analyzed, 
and  linking  to  external  systems  for  display  and  computation.  The  system  is  not  “read 
data,  apply  algorithm,  print  solution,”  instead,  the  viewpoint  is  that  the  network  data 
model  is  central  and  read,  validate,  solve,  display,  link,  and  write  are  just  operators  that 
transfonn  the  data. 

The  NaG  Project  has  a  component  architecture  to  support  the  operations 
mentioned  above.  The  components  have  well-defined  interfaces  and  are  “loosely 
coupled”  in  the  sense  that  the  interfaces  are  minimal  and  abstract,  and  thus  encourage  the 
development  of  multiple  implementations  for  each  component. 

The  architecture  of  the  NaG  Project  presumes  there  will  be  multiple 
implementations  for  each  component.  This  encourages  the  development  of  an  open 
source  community,  where  sharing  of  components  allows  a  user  to  select  the  combination 
of  components  that  best  supports  their  application.  This  also  allows  individuals  who  want 
to  develop  a  new  algorithm,  innovative  data  structure,  visualization  tool,  or  analysis 
technique  to  concentrate  on  their  interest,  while  using  components  constructed  by  others. 
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This  component  architecture  supports  innovation  by  allowing  easy  access  to,  and  testing 
of,  new  components.  The  long-tenn  success  of  the  project  will  depend  on  the  continued 
willingness  of  people  to  contribute  innovative  components. 

One  important  activity  of  an  open  source  component  architecture  project  is  to 
construct  reference  implementations  that  demonstrate  that  components  that  satisfy  the 
interface  can  be  effectively  constructed.  Currently,  there  are  reference  implementations 
for  two  NAGReaders  (discussed  below),  a  NaGSchemaConstruct,  a  hash  table  based  data 
store,  a  visualization  tool  to  construct  tables  (shown  below),  a  visualization  system  to 
animate  time  series  data  over  a  map  (the  application  mentioned  below),  and  a  NaGWriter 
that  constructs  NaGML  data  files  and  comma-separated  output  to  link  to  an  Excel 
spreadsheet.  NaGReaders  access  a  data  file  and,  guided  by  information  in  the  file, 
optionally  invoke  another  program  that  constructs  a  schema  (XML  Schema)  for  the  file; 
optionally  validates  the  file  using  a  schema;  and  always  processes  the  file  to  construct  a 
“dataStore”  that  is  the  internal  representation  of  the  network.  Following  xml  practice,  if 
the  data  file  fails  validation,  it  should  not  be  processed.  The  details  of  the  flexible  data 
formats  that  NaGML  allows  do  not  persist  into  the  dataStore,  thus  an  application  can 
select  from  various  data  format/NaGReader  combinations  to  construct  the  same 
dataStore,  which  then  interacts  with  the  other  components. 

NaGML  as  a  Persistent  Data  Model 

NaGML  is  a  data  model  for  representing  data  about  points  and  relationships 
between  pairs  of  points.  While  this  is  by  no  means  a  model  of  everything,  it  is  clearly 
more  than  a  data  file  fonnat. 

Networks  and  graphs  have  the  interesting  property  that  intennediate  calculations 
and  algorithm  results  are  most  often  also  node  and  arc  properties.  Thus,  the  data  model  is 
not  just  for  input;  it  persists  through  calculations  that  modify  and  add  properties.  This 
suggests  a  data-centric  view,  where  algorithms  are  just  operators  on  the  data  that  add  and 
modify  properties,  while  the  network  structure  persists.  This  perspective  is  particularly 
valuable  when  an  application  or  process  consists  of  a  sequence  of  algorithms.  Another 
example  of  the  persistence  of  the  data  model  is  that  the  software  to  display  data  files  can 
also  be  used  for  static  or  dynamic  views  of  intermediate  calculations  and  for 
presentations  of  results. 

The  network  data  model  is  even  valuable  in  situations  where  network  tenninology 
is  not  used.  As  shown  below,  the  flexibility  of  NaGML  can  bring  network  and  graph 
tools  to  other  applications,  where  users  have  the  notion  of  points  and  lines,  even  if  they 
don’t  use  the  tenninology  of  networks,  graphs,  nodes,  and  arcs. 

Interoperability,  Schemas,  and  Validation 

New  and  emerging  requirements  for  interoperability  of  valid  data  (particularly 
across  the  Web)  place  a  new  set  of  demands  on  network  and  graph  data  representations. 
Fast,  high-volume  exchange  of  data  between  different  organizations  and  tightly  coupled 
applications  that  do  not  have  humans  in  the  process  must  be  very  concerned  that  data  file 
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errors  (in  structure  and  in  data  values)  do  not  corrupt  downstream  processing.  Thus,  each 
data  producer  and  consumer  must  guard  against  a  variety  of  data  errors.  Much  of  this 
responsibility  can  be  shifted  to  xml  validating  parsers  and  thus  greatly  reduce  the  amount 
of  error  checking  that  must  be  included  in  application  software.  The  details  in  the  design 
of  the  schema  used  for  validation  detennine  which  errors  can  be  identified  by  the  parser. 
The  “strength”  of  a  validation  is  a  measure  of  the  number,  scope,  and  kinds  of  errors  that 
can  be  identified. 

An  xml  language  is  a  set  of  xml  documents  that  conform  to  a  specification  that  is 
called  a  schema.  An  xml  language  is  defined  by  a  schema;  a  validation  is  applied  to  an 
xml  document  to  determine  if  it  conforms  to  the  schema  and  is  thus  part  of  that  xml 
language.  There  are  several  different  kinds  of  schemas  associated  with  xml  (DTD,  XML 
Schema,  RELAX  NG,  etc.)[14]  [5].  The  most  widely  used  of  the  comprehensive  schemas 
(this  excludes  DTD)  is  the  XML  Schema  defined  by  the  W3C[15].  The  schema  is 
distinguished  from  its  competitors  by  the  capitalization  of  the  X,  M,  L,  and  S  characters. 
Every  XML  Schema  document  is  also  an  xml  document.  Each  kind  of  schema  has  its 
own  characteristics  that  influence  the  definition  of  an  xml  language  and  determine  what 
errors  are  found  by  validation.  Here  we  discuss  XML  Schema  exclusively.  XML  Schema 
is  very  good  for  expressing  data  types  for  element  and  attribute  data  values.  XML 
Schema  provides  44  built-in  data  types  that  cover  numbers,  strings,  boolean,  time,  dates, 
etc.  (In  the  Figures  the  data  types  all  have  the  prefix  “xs:”  which  indicates  the  Namespace 
associated  with  XML  Schema;  the  prefix  will  be  omitted  when  discussing  the  data  types 
in  the  text.)  Data  values  can  be  further  constrained  with  restrictions  to  these  types  by 
applying  patterns  expressed  as  regular  expressions,  or  by  enumerating  choices.  The 
Figures  below  give  some  idea  of  the  range  and  detail  that  is  possible.  XML  Schema  is  a 
so-called  “closed”  schema  in  which  the  structure  of  the  document  and  the  name  of  all 
elements  must  be  included  in  the  schema.  A  NaGML  user  selects  the  names,  data  types, 
and  restrictions  for  their  data  (and  thus  describes  an  xml  language  for  their  data  files)  and 
a  NaGSchemaConstruct  component  constructs  an  XML  Schema  to  automatically  validate 
their  data. 

The  schema  defines  the  structure  and  the  content  of  the  data  file  and  identifies  as 
errors  only  deviations  from  this.  The  construction  of  the  schema  determines  which  errors 
will  be  caught  by  validation.  For  example,  a  data  item  that  should  be  “A  123”  could  be 
validated  to  be  a  string  (and  thus,  “this  is  data”  would  be  valid),  or  a  string  with  no  spaces 
and  beginning  with  a  letter,  or  as  an  English  upper  case  letter  followed  by  exactly  three 
digits,  etc.  The  examples  below  show  some  of  the  validation  that  XML  Schema  supports. 
The  construction  of  a  schema  for  an  xml  language  can  be  a  complex  engineering  task 
with  critical  issues  such  as  how  much  detail  to  include — more  detail  identifies  more 
possible  errors,  but  simultaneously  reduces  the  number  of  documents  that  conform  to  the 
schema.  Validation  cannot  catch  all  data  errors  (e.g.,  entering  “3187”  instead  of  “3817”), 
but  many  errors  can  be  caught  and  using  validating  parsers  to  check  the  data  is  preferable 
to  writing  application-specific  code. 

The  NaGML  design  philosophy  has  been  to  make  schemas  as  “strong”  as  possible 
and  thus  include  as  many  checks  as  possible  in  the  validation.  This  minimizes  the  error 
checking  that  a  NaGReader  must  do.  As  shown  in  the  next  section,  the  reference 
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implementations  of  the  components  have  achieved  this.  However,  validation  for  large 
data  files  can  be  very  demanding  on  computer  time  and  space  resources.  It  is  anticipated 
that,  in  particular  situations,  some  of  these  errors  may  not  be  possible  given  how  the  data 
is  constructed,  thus  it  is  unnecessary  to  check  for  them  during  validation.  For  some 
applications  (particularly  those  with  larger  data  files)  it  may  be  efficient  to  move  some 
error  checking  from  the  validation  to  the  reader.  Also,  the  effort  to  validate  a  data  file  can 
be  reduced  if  the  user  selects  only  certain  data  fonnats.  The  second  NaGReader  reference 
implementation  demonstrates  this.  The  user  has  several  options  to  control  the  scope  of 
validation. 

Data  Formats 

One  of  the  goals  of  NaGML  is  to  provide  flexible  data  fonnats  that  support  the 
full  range  of  common  network  data  formats.  The  focus  of  this  paper  is  to  demonstrate  the 
variety  of  data  file  formats  that  are  supported  and  the  data  validation  that  is  provided.  The 
following  examples  give  the  reader  the  opportunity  to  decide  to  what  extent  this  NaGML 
goal  has  been  achieved. 

The  first  thing  to  notice  about  the  examples  is  that  the  user  chooses  the  names  for 
node  and  arc  properties.  This  seems  like  a  fairly  basic  requirement,  but  in  fact,  the  design 
that  permits  this  is  the  most  innovative  part  of  the  NaGML  design.  XML  Schema 
supports  the  development  of  a  range  of  different  languages,  but  in  each  specific  language 
the  names  of  the  elements  are  fixed.  The  NaGML  mechanism  to  allow  users  to  select 
their  own  names  for  node  and  arc  properties,  and  to  specify  data  types  and  further 
restrictions  for  data  values,  is  described  in  a  companion  paper  written  for  an  xml 
audience.  It  is  not  exaggeration  to  say  that  the  NaG  Project  would  not  have  been  possible 
without  this  innovation  to  common  xml  practice. 

The  second  thing  to  notice  is  the  wide  variety  of  data  types  that  are  supported. 
While  it  might  seem  sufficient  for  most  operations  research  applications  to  have  only 
integer  and  double  properties,  the  extension  to  strings,  booleans,  times,  dates,  lat-long, 
URLs,  etc.  is  essential  for  the  full  range  of  network  applications.  As  mentioned  below, 
the  first  application  of  NaGML  was  an  operations  research  analysis  where  only  a  few  of 
the  properties  are  integer  or  double. 

Finally  notice  that  NaGML  can  be  extended  to  applications  where  the  terms 
“node,”  “arc,”  “set,”  and  “property”  are  replaced  by  equivalent  terms  that  are  more 
familiar  to  users  in  a  social  science  community. 

The  first  example  is  shown  in  Figure  1.  The  Description  element  contains  the 
specification  of  each  property.  The  NaGReader  reads  the  data  file  and  invokes  a 
NaGSchemaConstruct  program  to  construct  the  appropriate  schema  and  validate  the 
topology  and  property  data  values.  It  then  constructs  a  “dataStore”  that  contains  the 
topology,  properties,  and  data  type  information.  Figure  2  shows  a  table  view  of  the  arc 
properties.  The  table  is  constructed  from  information  in  the  dataStore.  Note  that  by  user 
option,  missing  data  values  are  displayed  as  blanks  (rather  than  0  or  0.0).  The  user  can 
select  any  column  to  sort  the  rows. 
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Figure  2  Table  view  of  the  arc  property  values  from  the  Figure  1  data  file. 

Each  node  and  each  arc  has  a  unique  identifier,  nodelD  or  arcID.  In  Figure  1,  the 
defaults  are  used;  nodelD  is  an  integer  and  is  assigned  in  each  Node  element.  For  the 
default,  the  nodelD  values  need  not  be  in  order  in  the  data  file  or  contiguous  integers  (or 
even  positive).  The  validation  process  checks  that  each  nodelD  is  a  legal  integer  and  each 
node  has  a  unique  value.  The  default  for  arcID  is  integers  1,2,  ...  assigned  in  the  order 
the  arc  appears  in  the  data  file  (called  “document  order”).  The  validation  checks  that  each 
head  and  tail  attribute  is  assigned  to  one  of  the  nodes  declared  in  the  data  file. 

This  format  shows  that  with  only  a  small  amount  of  training  a  user  can  quickly 
construct  a  small  network.  The  plans  for  the  NaG  Project  include  having  input  from 
spreadsheets,  databases,  forms,  and  Web  browsers  that  will  allow  even  simpler  access  to 
NaGMF  capabilities. 

This  data  format  allows  any  number  of  nodes  and  arcs.  As  shown  in  subsequent 
examples,  there  is  no  restriction  on  the  ordering  of  nodes  and  arcs  and  no  requirement 
that  nodes  precede  arcs. 

In  the  subsequent  Figures,  the  defaults  are  explicitly  included  in  order  to  show 
where  and  how  the  parameters  of  the  system  are  specified.  In  Figure  3,  the  nodelD  is  still 
integer,  however,  the  user  has  specified  the  exact  number  of  nodes  and  their  nodelD  by 
specifying  the  attribute  declared  =  “10  to  13.”  The  validation  enforces  that  there  will  be 
exactly  4  nodes  with  the  specified  nodelDs.  The  arcID  is  specified  to  be  a  string  and  the 
attribute  declared  =  “Arcs  only”  indicates  that  they  will  be  specified  in  the  Arc  elements. 
The  arcIDs  can  be  any  string,  but  the  string  must  be  unique  for  each  arc.  Duplicate  arcs 
(each  with  a  different  arcID)  are  allowed.  The  validation  checks  each  property  value, 
which  now  includes  string,  date,  and  boolean  values.  The  integer  node  properties  x  and  y 
specify  pixel  locations  in  order  that  a  NaGViewer  can  display  the  network.  The  integers 
are  restricted  so  the  nodes  will  appear  inside  a  window  that  is  400  by  600  pixels. 

<?xml  version="l . 0"  encoding="UTF-8"?> 

<!--  NetworkAndGraphML  for  networks  and  graphs  --> 

<NaGXML  xmlns : xsi="http : / /www . w3 . org/ 2001 /XMLSchema- instance" 
xsi : noNamespaceSchemaLocation="Figure3 . xsd"> 

<Description> 

<Network  name="Figure  3"  arcType="directed" 
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dataFormat=" general"  validate="true" /> 

<NodeID  nodeIDDataType="xs : integer"  declared="10  to  13"/> 

<ArcID  arcIDDataType="xs : string"  declared="Arcs  only"/> 
<NodeProperties> 

<NodeProperty  name="Xpixel"  dataType="xs : nonNegativelnteger" 
maxInclusive="400"/> 

<NodeProperty  name="Ypixel"  dataType="xs : nonNegativelnteger" 
maxInclusive="600"/> 

<NodeProperty  name="Symbol"  dataType="xs : string"/> 
<NodeProperty  name="DateConstructed"  dataType="xs : date"/> 
</NodeProperties> 

<ArcProperties> 

<ArcProperty  name="Length"  dataType="xs :double"/> 

<ArcProperty  name="RoadOpen"  dataType="xs :boolean"/> 
</ArcProperties> 

</Description> 

<Data> 

<Arc  arcID="a-23"  tail  ="12"  head="13"> 

<Length>160 . 0</Length> 

</Arc> 

<Node  nodeID="10"> 

<Xpixel>100</Xpixel> 

<DateConstructed>2001-04-23</DateConstructed> 

<Ypixel>100</Ypixel> 

<Symbol>black  circle</Symbol> 

</Node> 

<Node  nodeID="12"/> 

<Node  nodeID="ll"> 

<DateConstructed>l 990-1 0-1 0</DateConstructed> 
<Xpixel>300</Xpixel> 

<Ypixel>200</Ypixel> 

<Symbol>blue  square</Symbol> 

</Node> 

<Arc  arcID="unknown"  tail  ="11"  head="12"> 

<Length>120 . 4</Length> 

</Arc> 

<Node  nodeID="13"> 

<Xpixel>350</Xpixel> 

<Ypixel>125</Ypixel> 

<DateConstructed>l 954-01-2 6</DateConstructed> 

</Node> 

<Arc  arcID="San  Francisco"  tail  ="13"  head="10"> 

<Length>34 . 5</Length> 

</Arc> 

<Arc  arcID="Washington"  tail  ="12"  head="13"> 

<Length>200 . 0</Length> 

</Arc> 

<Arc  arcID="warehouse  1"  tail  ="12"  head="ll"/> 

</Data> 

</NaGXML> 

Figure  3  Data  format  with  nodelD  specified  10  to  13  and  arcID  declared  in  each 

Arc  element. 
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NaG  Table:  node  list  to  node  properties  list 


Sort-Asc.  Sort-Des.  Horz.  Lines  Vert.  Lines  +  Row  Height  -  Row  Height 

Save  table  (.csv) 

InodelD 

Xpixel 

Ypixel 

Symbol 

DateConstructed 

10 

100 

100 

black  circle 

2001-04-23 

11 

300 

200 

blue  square 

1990-10-10 

12 

13 

350 

125 

blue  square 

1954-01-26 

Figure  4  Table  view  of  the  node  property  values.  This  is  one  of  16  different  views  of 
the  data. 

In  the  previous  Figures  there  is  a  Node  element  for  each  node.  Some  networks 
have  no  node  properties;  a  common  data  format  for  this  lists  only  the  arcs  with  the 
implication  that  there  should  be  a  node  created  for  the  tail  and  head  nodes  specified.  The 
NodelD  declared  =  “Nodes  then  Arcs”  indicates  that  a  node  is  created  for  each  Node 
element  in  the  data  file.  In  addition,  absent  a  Node  element,  any  node  referred  to  in  an 
Arc  element  is  created.  This  option  can  be  used  even  if  there  are  node  properties;  in  that 
case,  a  Node  element  is  required  only  if  the  node  has  a  nonempty  property. 

Figure  5  also  shows  that  it  is  possible  to  enumerate  the  possible  values  that  an  arc 
(or  node)  property  can  assume.  The  Figure  shows  this  for  a  string  property  but  this  works 
equally  well  for  other  data  types. 

Many  network  algorithms  use  a  “forward  star”  data  store  where  all  the  arcs  with 
the  same  tail  node  are  stored  contiguously.  Sometimes  it  is  convenient  to  have  this 
reflected  in  the  data  file  (if  the  data  is  stored  forward  star  it  is  easy  for  a  NaGWriter  to 
create  a  NaGML  data  file  with  this  organization.)  Figure  7  shows  all  the  data  in  forward 
star  form.  NaGML  also  supports  reverse  star,  which  is  not  shown.  Forward  star  and 
reverse  star  data  format  can  be  combined  with  any  of  the  fonnats  shown  in  the  previous 
Figures. 


<?xml  version="l . 0"  encoding="UTF-8"?> 

<!--  NetworkAndGraphML  for  networks  and  graphs  --> 

<NaGXML  xmlns : xsi="http : / /www . w3 . org/ 2001 /XML Schema- instance" 
xsi : noNamespaceSchemaLocation="Figure5 . xsd"> 

<Description> 

<Network  name="Figure  5"  arcType="directed" 
dataFormat=" general"  validate="true" /> 

<NodeID  nodeIDDataType="xs : string"  declared="Nodes  then  Arcs"/> 
<ArcID  arcIDDataType="xs : string"  declared="Arcs  only"/> 
<ArcProperties> 

<ArcProperty  name="Length"  dataType="xs :double"/> 
<ArcProperty  name="RoadCondition"  dataType="xs : string"> 
<Enumeration>closed</Enumeration> 
<Enumeration>open</Enumeration> 

<Enumeration>open  if  dry</Enumeration> 
<Enumeration>unknown</Enumeration> 

</ArcProperty> 
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="Boston"  head="New  York"> 


</ArcProperties> 

</Description> 

<Data> 

<Arc  arcID=" I  80"  tail 

<Length>160 . 0</Length> 

<RoadCondition>open</RoadCondition> 

</Arc> 

<Arc  arcID="I  40"  tail  ="New  York"  head="Chicago"> 

<Length>120 . 4</Length> 

<RoadCondition>open  if  dry</RoadCondition> 

</Arc> 

<Arc  arcID=" I-80W"  tail  ="Chicago"  head="Denver"> 

<Length>34 . 5</Length> 

<RoadCondition>closed</RoadCondition> 

</Arc> 

<Arc  arcID="the  101"  tail  ="Los  Angeles"  head="San  Diego"/> 

<Arc  arcID="the  10"  tail  ="Los  Angeles"  head="Phoenix"> 
<RoadCondition>unknown</RoadCondition> 

<Length>200 . 0</Length> 

</Arc> 

</Data> 

</NaGXML> 

Figure  5  Data  format  with  the  nodes  implicitly  declared  and  an  arc  property 

enumerated. 


Figure  6  Node-arc  incident  matrix  for  the  data  (a  node  adjacency  matrix  is  also 

available). 

<?xml  version="l . 0"  encoding="UTF-8"?> 

<!--  NetworkAndGraphML  for  networks  and  graphs  :  --> 

<NaGXML  xmlns : xsi="http : / /www . w3 . org/ 2001 /XML Schema- instance" 
xsi : noNamespaceSchemaLocation="Figure7 . xsd"> 

<Description> 

<Network  name="Figure  7"  arcType="directed" 
dataFormat=" general"  validate="true" /> 

<NodeID  nodeIDDataType="xs : string"  declared=" list">12  34  14  23  - 
3</NodeID> 

<ArcID  arcIDDataType="xs : NMTOKEN"  declared=" list"> 

12to34  34tol4  14to23  14to23Again 
</ArcID> 
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<NodeProperties> 

<NodeProperty  name="StartTime"  dataType="xs : time"/> 
<NodeProperty  name="Signal"  dataType="xs : integer"/> 
</NodeProperties> 

<ArcProperties> 

<ArcProperty  name="Cost"  dataType="xs :double"/> 

</ArcProperties> 

</Description> 

<Data> 

<Node  nodeID="12"> 

<StartTime>13 : 23 : 59</ StartTime> 

<Signal>-345</ Signal> 

<ArcTail  arcID=" 12to34 "  head="34"> 

<Cost>  34.56  </Cost> 

</ArcTail> 

</Node  > 

<Node  nodeID="14"> 

<StartTime>01 : 45 : 00</ StartTime> 

<Signal>0</ Signal> 

<ArcTail  arcID="14to23"  head="23"> 

<Cost>  26.99  </Cost> 

</ArcTail> 

<ArcTail  arcID="14to23Again"  head="23"> 

<Cost>  0.00  </Cost> 

</ArcTail> 

</Node  > 

<Node  nodeID="34"> 

<ArcTail  arcID="34tol4"  head="14"> 

<Cost>  -23.00  </Cost> 

</ArcTail> 

<StartTime>23 : 23 : 23</ StartTime> 

<Signal>222</ Signal> 

</Node  > 

<Node  nodeID="-3"/> 

<Node  nodeID="23"> 

<StartTime>12 : 00 : 00</ StartTime> 

<Signal>444</ Signal> 

</Node  > 

</Data> 

</NaGXML> 

Figure  7  Data  file  with  forward  star  format  and  lists  of  nodelDs  and  arcIDs. 

As  shown  in  Figure  7,  the  user  can  specify  a  lists  of  nodelDs  and  arcIDs  that  must 
be  used  in  the  Data  element.  The  validation  checks  that  these,  and  only  these,  are  used  in 
the  Data  element.  Lists  of  values  in  xml  must  be  space  separated  (comma  separated  lists 
can  be  used,  but  they  are  treated  as  a  single  string  and  thus  are  not  subject  to  the 
validation  of  the  individual  values  that  we  demand).  This  means  that  values  in  lists 
cannot  contain  leading,  trailing,  or  embedded  spaces.  Thus,  while  “San  Francisco”  can  be 
used  as  a  nodelD,  arcID,  or  property,  it  cannot  be  used  in  a  list.  The  XML  Schema  data 
types  include  a  restricted  string  type,  NMTOKEN,  that  does  not  allow  leading,  trailing,  or 
embedded  spaces.  If  the  user  intends  to  forbid  spaces  in  the  nodelD,  arcID,  or  a  property, 
specifying  this  restricted  data  type  allows  the  validation  to  enforce  the  no  spaces  decision. 
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Figure  8  Table  view  of  the  data  in  forward  star  format  (reverse  star  is  also 

available). 

The  loosely  coupled  components  architecture  guarantees  that  the  data  file  format 
is  completely  independent  of  the  dataStore,  so  the  display  of  the  data  in  the  tables  does 
not  depend  in  any  way  on  the  format  of  the  data  file. 

One  of  the  advantages  of  xml  is  that  the  data  is  represented  as  character  data  (as 
opposed  to  binary  formats  that  may  be  computer  dependent)  so  it  is  “human  readable.” 
This  encourages  the  descriptive  (and  often  long)  names  for  the  properties  that  help  to 
document  the  data  files.  In  the  resulting  data  files  the  ratio  of  markup  to  data  values  can 
be  high.  This  is  appropriate  for  files  that  are  constructed  and  read  by  people.  For  large 
data  files,  and  for  data  files  that  are  constructed  and  consumed  by  computer  programs 
without  human  interaction  with  the  data,  it  is  useful  to  reduce  this  markup.  (Note:  It  is  not 
clear  that  reducing  the  markup  is  necessary  even  for  very  large  data  files  because  xml 
files  can  be  efficiently  and  effectively  compressed.)  One  mechanism  is  to  shorten  the 
property  names  as  shown  in  Figure  9.  As  shown  in  the  NodeProperty  and  ArcPropery 
elements,  there  is  an  optional  attribute  label  that  provides  a  name  that  can  be  used  in 
generating  reports  or  when  the  data  is  viewed  by  people. 

There  are  several  other  ways  to  reduce  markup.  As  shown  for  the  Node  element 
“123,”  nonempty  node  data  can  be  included  as  attributes.  This  format  is  also  a  compact 
way  to  keep  all  the  data  associated  with  a  node  (or  arc)  together  in  the  data  file.  Node 
property  Location  is  entered  so  that  the  values  of  a  single  property  are  kept  together  in  the 
data  file.  The  data  is  in  a  space-separated  list.  The  order  of  the  data  must  conform  to  the 
order  of  the  nodes  in  the  data  file.  This  ordering  is  unambiguous  for  each  of  the  four 
different  ways  to  assign  nodelDs  (and  each  of  the  four  ways  to  assign  arcIDs). 


<?xml  version="l . 0"  encoding="UTF-8"?> 

<!--  NetworkAndGraphML  for  networks  and  graphs  --> 

<NaGXML  xmlns : xsi="http : / /www . w3 . org/ 2001 /XMLSchema- instance" 
xsi : noNamespaceSchemaLocation="Figure9 . xsd"> 

<Description> 

<Network  name="Figure  9"  arcType="directed"  dataFormat="general" 
validate="true"/> 

<NodeID  nodeIDDataType="xs : integer"  declared="Nodes  only"/> 
<ArcID  arcIDDataType="xs : integer"  declared="automatic"/> 
<NodeProperties> 
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<NodeProperty  name="T"  dataType="xs : time"  label="Time"/> 
<NodeProperty  name="S"  dataType="xs : integer"  label="Special 

Signal"/> 

<NodeProperty  name="Location"  dataType="xs : string"/> 
</NodeProperties> 

<ArcProperties> 

<ArcProperty  name="C"  dataType="xs : double"  label="Cost"/> 
<ArcProperty  name="Value"  dataType="xs : double" 
default="100 . 0"/> 

<ArcProperty  name="AnotherValue"  dataType="xs : integer" 
defaultlnsert="0 . 0"/> 

</ArcProperties> 

</Description> 

<Data> 

<Node  nodeID="123"> 

<NodeValues  nodeID="123"  S="-345"  T=" 13 : 23 : 59" /> 

</Node> 

<NodeListValuesAll> 

<Location>  A1  A2  B1  B2  B3  Cl  C4</Location> 

</NodeListValuesAll> 

<Node  nodeID="12"> 

<NodeValues  nodeID="12"  S="45"  T="10 : 23 : 59"/> 

</Node> 

<Node  nodeID="100"> 

<NodeValues  nodeID="100"  T="00 : 00 : 00"/> 

</Node> 

<Node  nodeID="101"> 

<NodeValues  nodeID="101"  T="01 : 00 : 00"/> 

</Node> 

<Node  nodeID=" 1 02 "> 

<NodeValues  nodeID="102"  T="02 : 00 : 00"/> 

</Node> 

<Arc  head="123"  tail="23"> 

<023 . 45</C> 

</Arc> 

<Arc  head="123"  tail="23"XC>23 . 45</CX/Arc> 

<Arc  head="100"  tail="101"> 

<C>00.45</C> 

</Arc> 

<Arc  head="101"  tail="100"> 

<023 . 00</ C> 

<Value>23 . 23</Value> 

</Arc> 

<Node  nodeID="-3"/> 

<Node  nodeID="23"> 

<T>12 : 00 : 00</T> 

<S>444</ S> 

</Node  > 

</Data> 

</NaGXML> 

Figure  9  Data  file  with  short  property  names,  property  input  as  attributes,  and 

property  lists. 

Assigning  default  values  for  node  or  arc  properties  (see  arc  property  Value)  can 
reduce  the  size  of  the  data  file.  The  default  value  is  passed  to  the  dataStore;  a  NaGReader 
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places  the  value  into  the  dataStore  only  if  the  attribute  defaultlnsert  is  specified  (see  arc 
property  AnotherValue). 


Figure  10  shows  the  use  of  node  lists  and  arc  lists  that  offer  yet  another  way  to 
organize  the  data  file.  This  fonnat  is  useful  if  the  property  values  are  nonempty  for  only  a 
recognized  subset  of  the  data.  In  addition  to  data  entry,  node  sets  and  arc  sets  are  useful 
to  specify  a  part  of  the  structure  of  the  network  and  can  be  used  to  specify  subgraphs.  All 
node  and  arc  sets  and  subgraphs  are  carried  on  into  the  dataStore  so  they  can  be  used  in 
algorithms,  displays,  and  output  files. 


<?xml  version=" 1 . 0"  encoding="UTF-8"?> 

<!--  NetworkAndGraphML  for  networks  and  graphs  :  --> 

<NaGXML  xmlns : xsi="http : // www . w3 . org/ 2001 /XMLSchema- instance" 
xsi : noNamespaceSchemaLocation="FigurelO . xsd"> 

<Description> 

<Network  name="Figure  10"  arcType="directed" 
dataFormat=" general"  validate="true" /> 

<NodeID  nodeIDDataType="xs : integer"  declared="Nodes  only"/> 

<ArcID  arcIDDataType="xs : string"  declared="Arcs  only"/> 
<NodeProperties> 

<NodeProperty  name="Name"  dataType="xs : string"/> 

<NodeProperty  name="Location"  dataType="xs : string"/> 
<NodeProperty  name="Time"  dataType="xs : integer"  label="Z 

time"/> 

<NodeProperty  name="Date"  dataType="xs : string"/> 

<NodeProperty  name="LatLong"  dataType="xs : string"/> 
<NodeProperty  name="Costl"  dataType="xs : double" 
label="operations  cost"/> 

<NodeProperty  name="Cost2"  dataType="xs : double" 
minlnclusive=" 4 . 0" 

maxlnclusive="7 . 0"  /> 

<MultipleNodeProperties  name="BothCosts"  dataType="xs : double"> 
Costl  Cost2</MultipleNodeProperties> 

<MultipleNode Properties  name="RestrictedCostl " 
dataType="xs : double" 

minlnclusive="4 . 0" 

maxlnclusive=" 5 . 0">Costl</MultipleNodeProperties> 

</NodeProperties> 

<ArcProperties> 

<ArcProperty  name="Name"  dataType="xs : string"/> 

<ArcProperty  name="Capacity"  dataType="xs : integer" 
default="3"/> 

</ArcProperties> 

<NodeLists> 

<NodeList  nodeListName="SomeNodes">2  4  6  </NodeList> 

<NodeList  nodeListName="OtherNodes">3  5</NodeList> 

</NodeLists> 

<ArcLists> 

<ArcList  arcListName="SomeArcs">Al  A3</ArcList> 

<ArcList  arcListName="OtherArcs">A2  Al</ArcList> 

</ArcLists> 

</Description> 

<Notes> 

< Processing  node Pr oper t yDupli cat e=" replace" 

ar c Pr ope rtyDuplicate=" replace"  er r o rMe ss age s= "prompt" /> 
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<Comment  name="create  date">10  May  2004</Comment> 

<Comment  name="author">G .  Bradley</Comment> 

</Notes> 

<Data> 

<Node  nodeID="l"> 

<LatLong>N36  45  12  W104  56  12</LatLong>> 

<BothCosts>4 . 3  5 . 6</BothCosts> 

</Node> 

<Node  nodeID="2"> 

<Date>  2004-05-10</Date> 

</Node> 

<Node  nodeID="3"> 

<RestrictedCostl>4 . 5</RestrictedCostl> 

</Node> 

<Node  nodeID="4"> 

<BothCosts>4 . 43  5 . 4 6</BothCosts> 

</Node> 

<Node  nodeID="5"> 

<BothCosts>14 . 3  35 . 6</BothCosts> 

</Node> 

<Node  nodeID="6"> 

<RestrictedCostl>4 . 4445</RestrictedCostl> 

</Node> 

<Arc  arcID  ="A1"  tail="l"  head="3"> 

<Name>San  Francisco</Name> 

</Arc> 

<Arc  arcID  ="A2"  tail— "3"  head="5"> 

<Name>Atlanta</Name> 

</Arc> 

<Arc  arcID  ="A3"  tail="5"  head="3"> 

<Name>Dallas</Name> 

</Arc> 

<Arc  arcID  ="A4"  tail="6"  head="3"/> 

<SubGraph  name="somePart"  nodeListName="someNodes" 
arcLi stName=" someArcs " /> 

</Data> 

</NaGXML> 

Figure  10  Data  file  with  node  and  arc  property  lists  and  multiple  property 

elements. 

It  is  sometimes  convenient  to  group  some  of  the  node  properties  into  a  list.  This 
may  be  to  reduce  markup  or  just  to  keep  related  data  values  together.  A 
MultipleNodeProperty  is  defined  by  a  list  of  node  properties.  The  basic  philosophy 
behind  NaGML  is  that  every  data  value  should  be  subject  to  validation  and  that  validation 
should  be  as  “strong”  as  possible.  XML  Schema  validation  allows  only  one  data  type  for 
items  in  a  list.  For  this  reason,  each  MultipleNodeProperty  must  have  its  own  data  type 
(plus  any  appropriate  restrictions).  As  shown  for  MultipleNodeProperty  BothCosts,  this 
usually  means  a  relaxation  of  the  data  type  to  allow  values  from  all  the  properties. 
However,  it  can  also  be  used  to  further  restrict  a  property  value  as  shown  for 
MultipleArcProperty  RestrictedCostl.  The  property  Costl  can  be  entered  in  a  Costl 
element  or  a  RestrictedCostl  element;  for  the  fonner  the  validation  checks  that  the  value 
is  double,  for  the  later  additional  restrictions  are  imposed. 
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The  MultipleNodeProperty  and  MultipleArcProperty  are  carried  on  into  the 
dataStore.  One  use  is  to  restrict  the  data  displays  for  networks  with  large  numbers  of 
properties  or  to  construct  custom  displays  and  reports  or  to  create  new  data  files  with  a 
subset  of  the  properties.  Figure  1 1  shows  the  data  from  Figure  10  where  the  NodeSet 
SomeNodes  and  the  MultipleNodeProperty  BothCosts  are  used  to  define  which  nodes 
and  node  properties  are  displayed. 


Figure  11  Data  display  from  Figure  10  file  that  demonstrates  two  ways  to  enter 

property  data. 

The  validation  of  each  data  file  checks  the  data  type  and  restrictions  for  each 
nodelD,  arcID,  and  property  value  and  checks  that  nodelDs  and  arcIDs  are  unique. 
However,  the  great  variety  in  the  ways  that  a  data  value  can  be  included  in  the  data  file 
makes  it  impractical  to  check  if  a  data  value  has  been  specified  in  the  Data  element  more 
than  once.  This  can  be  viewed  as  a  valuable  feature  in  that  additional  data  can  be  added  to 
the  end  of  a  (perhaps  large)  data  file  to  update  a  value  in  the  file.  The  data  file  author  has 
control  over  what  a  NaGReader  does  whenever  a  duplicate  property  value  is  encountered. 
The  Notes  element  includes  an  optional  element  Processing  that  includes  directions  that 
are  passed  on  to  a  NaGReader.  The  user  can  specify  that  a  duplicate  value  replaces  the 
previous  value,  is  ignored,  or  causes  a  fatal  error.  The  specification  for  NaGReaders 
details  the  order  that  the  elements  must  be  processed,  thus  the  definition  of  “previous”  is 
unambiguous  (see  Figure  10). 

In  addition  to  the  restrictions  on  the  data  types  that  have  been  shown  in  the 
previous  Figures,  it  is  also  possible  to  specify  a  regular  expression  (using  the  attribute 
pattern )  to  further  restrict  the  value  of  nodelD,  arcID,  and  property  values.  XML  Schema 
includes  a  powerful  regular  expression  capability  based  on  UNIX  and  Perl  regular 
expressions  (“based”  means  there  are  a  few  nonobvious  exceptions).  Regular  expressions 
are  a  powerful  capability  to  tightly  specify  the  format  and  values  of  special  data  values 
(for  example,  lat-long,  nonstandard  times  and  dates,  phone  numbers,  serial  numbers, 
etc.);  however,  the  processing  cost  can  be  significant. 

Graphs  and  networks  have  been  around  for  hundreds  of  years  and  they  are  used  in 
a  wide  variety  of  contexts.  It  is  important  for  NaGML  to  support  a  wide  range  of  data  file 
formats  in  order  to  expedite  the  transition  to  a  standard  data  file  format.  The  requirement 
to  simultaneously  support  all  the  data  formats  shown  in  the  previous  Figures  is  indicated 
in  the  attribute  dataFormat  =  “general”  in  the  Description  element.  This  dataFormat  is 
supported  with  the  reference  implementation  reader,  which  uses  the  JDOM  API  [11]  to 
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access  and  then  process  the  elements  in  a  fixed  sequence.  JDOM  constructs  a  tree 
structure  for  an  xml  document  in  memory.  This  allows  “random”  access  to  all  parts  of  the 
representation  of  the  data  file,  thus  the  dataFormat  =  “general”  adds  only  a  small 
additional  computational  cost  to  allow  the  top-level  elements  in  the  Data  element  to 
appear  in  any  order. 

For  larger  data  files  the  construction  of  a  DOM  is  not  practical;  the  most  effective 
way  to  read  the  data  file  is  in  a  single  pass.  This  can  be  done  using  an  xml  SAX  parser  or 
by  constructing  a  program  to  read  the  file  directly  (as  done  in  the  second  NaGReader 
reference  implementation).  The  attribute  dataFormat  in  the  Description  element  specifies 
the  structure  that  the  user  has  selected  for  the  contents  of  the  Data  element.  As  shown  in 
the  previous  Figures,  the  choice  of  “general”  offers  the  greatest  choice  of  structure  and 
order.  The  choice  of  “one  pass”  means  that  the  schema  that  is  constructed  for  this  data 
file  must  guarantee  that  any  NaGReader  can  read  the  data  file  in  a  single  pass  through  the 
file.  One  pass  imposes  several  “define  before  use”  restrictions  that  must  be  enforced  in 
the  validation.  In  particular,  since  each  arc  requires  a  reference  to  a  tail  node  and  a  head 
node  that  should  be  defined  before  the  arc,  all  node  elements  must  precede  all  arc 
elements  and  ArcTail  and  ArcHead  elements  are  not  allowed  inside  Node  elements.  Also 
the  NodeList  and  ArcList  elements  (in  the  Data  element)  should  follow  the  Node  and  Arc 
elements.  The  schema  that  is  constructed  enforces  this  ordering. 

There  are  a  number  of  different  choices  that  could  be  made  to  limit  the  data  file 
format  and  thus  allow  more  efficient  readers.  The  only  restriction  on  extending  NaGML 
in  this  way  is  that  the  schema  that  is  constructed  must  enforce  the  restrictions  on  structure 
and  order,  and  any  NaGReader  should  refuse  to  read  a  file  that  has  a  fonnat  it  cannot 
correctly  process. 


<?xml  version="l . 0"  encoding="UTF-8"?> 

<!--  Social  Network  for  people  and  relationships  :  --> 

<NaGXML  xmlns : xsi="http : / /www .w3.org/ 2001 /XMLSchema- instance" 
xsi : noNamespaceSchemaLocation="Figurel2 . xsd"> 

<Description> 

<SocialNetwork  name="Figure  12"  relationships="reciprocal" 
dataFormat=" general"  validate=" true" /> 

<PeopleNumber  peopleNumberDataType="xs : integer"  declared=" People 
only"/> 

<RelationshipNumber  RelationshipNumberDataType="xs : string" 
declared=" Relationships  only" /> 

< People Properties> 

<PeopleProperty  name="Name"  dataType="xs : string"/> 
<PeopleProperty  name="Location"  dataType="xs : string"/> 
<PeopleProperty  name="Age"  dataType="xs :positiveInteger"/> 
<PeopleProperty  name="Gender"  dataType="xs : string"> 
<Enumeration>male</Enumeration> 
<Enumeration>female</Enumeration> 

</ People Proper ty> 

</ People Pr ope rties> 

<RelationshipProperties> 

<RelationshipProperty  name="Type"  dataType="xs : string"/> 
<RelationshipProperty  name="TimeEstablished" 
dataType="xs : time"  /> 
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</RelationshipProperties> 

<PeopleLists> 

<PeopleList  PeopleListName=" SomePeople">2  4  6  </PeopleList> 
</PeopleLists> 

<RelationshipLists> 

<RelationshipList  RelationshipListName="SomeRelationships"> 

A1  A3</RelationshipList> 

</RelationshipLists> 

</Description> 

<Notes> 

< Processing  People Pr oper t yDupli cat e=" replace" 

Relat ionshipPropertyDuplicate=" replace " /> 

<Comment  name="create  date">12  Feb  2004</Comment> 

<Comment  name="author">G .  Bradley</Comment> 

</Notes> 

<Data> 

<People  PeopleID=" 1 "> 

<Name>John  Jones</Name» 

<Age>42</Age> 

</People> 

etc .  .  . 

<Clique  name="somePart"  PeopleListName=" somePeople" 

Relat ionshipLi s tName= " someRelat ionships " /> 

</Data> 

</NaGXML> 

Figure  12  A  partial  data  file  that  shows  NaGML  support  for  different  element 

names. 

As  discussed  earlier,  NaGML  is  intended  for  an  international  community  and  thus 
has  been  constructed  so  that  the  visible  parts  of  the  markup  (element  and  attribute  names) 
can  be  changed  to  different  languages  (xml  encodings).  In  the  reference  implementation, 
NaGReaders  access  the  names  of  elements  and  attributes  through  a  list  of  string 
constants.  Thus,  any  change  in  this  list  changes  the  text  of  the  markup  without  modifying 
any  of  the  code.  In  the  same  way,  NaGML  can  be  modified  to  construct  tools  for 
communities  that  work  with  points  and  lines,  but  who  have  a  vocabulary  that  does  not 
include  nodes  and  arcs.  Figure  12  is  an  example  of  a  data  file  format  that  could  be 
supported. 

Related  Work 

The  first  application  of  NaGML  uses  many  of  the  components  described  here.  It  is 
an  application  to  track  military  incidents  and  to  analyze  them  for  patterns  that  are 
changing  over  time.  Each  incident  (node)  has  34  properties,  only  a  few  of  which  are 
integers  or  doubles.  Data  collection  has  begun  and  a  software  system  to  collect,  visualize, 
and  analyze  the  data  has  been  deployed.  This  work  will  be  reported  elsewhere. 

The  author  of  a  NaGML  data  file  specifies  the  name,  data  type,  and  restrictions 
for  each  node  and  arc  property.  This  is  the  most  innovative  feature  of  NaGML.  Previous 
proposals  for  xml  languages  for  networks  and  graphs  have  significant  limitations  on  what 
can  be  in  a  data  file  and  what  validation  can  be  applied  [7]  [  12]  [9]  [  1  ] . 
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There  are  proposed  xml  standards  for  optimization  that  cover  linear,  nonlinear, 
integer,  and  stochastic  programming  [6]  [9]  [10].  Network  optimization  problems  can  be 
modeled  as  more  general  optimization  problems,  however,  these  system  do  not  have 
special  markup  for  network  problems. 

There  have  been  previous  systems  to  support  the  construction  and  execution  of 
graph  and  network  algorithms  [3].  The  availability  of  xml,  and  the  development  of 
NaGML,  addresses  many  of  the  deficiencies  in  pre-xml  systems. 

NaGML — the  Design  Challenge  and  the  Road  Forward 

The  adoption  of  new  technology  (xml)  involves  costs  to  the  potential  users  of 
NAGML,  thus  the  challenge  is  to  provide  sufficient  benefits  (for  example,  validation, 
readers,  writers,  connections  to  other  data  sources,  displays)  and  easy  entry  (familiar, 
easy  to  leam  and  use  data  file  formats).  The  design  challenge  is  to  address  all  of  the 
sometimes  conflicting  design  criteria  (wide-spread  adoption,  loosely  coupled  components 
architecture,  flexible  data  format,  and  strong  validation)  without  sacrificing  any  one  of 
them.  The  dynamic  construction  of  NaGML  schemas  provides  strong  validation  with  no 
loss  of  flexibility.  The  other  design  criteria,  and  full  details  on  the  NaGML  architecture 
and  the  reference  implementation  of  several  components,  are  described  in  detail 
elsewhere. 

A  further  challenge  for  the  NaG  Project  is  to  evolve  a  component  architecture  that 
helps  create  an  open  source  community  that  will  support  the  independent  development  of 
components  by  many  people. 

Other  data  formats  (in  particular,  databases  and  spreadsheets)  have  announced 
xml  formats  with  accompanying  schemas.  One  task  of  the  NaG  Project  is  to  replace  the 
existing  components  that  link  to  spreadsheets  via  comma-separated  lists  with  connections 
based  on  NaGML  and  the  corresponding  schemas  of  other  documents.  This  will  add 
support  for  validation  as  well  as  provide  access  to  the  capabilities  of  these  systems. 
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